Transmission Control Protocol (TCP) is the most common transport protocol currently used in data communication networks such as the internet. TCP is designed for use in traditional wired networks in which the dominant cause for packet losses and delays is congestion. Congestion occurs, for example, when a transmitting host sends too many packets too quickly over the network to a receiving host, causing some packets to be lost because the receiving host cannot handle such high throughput. In TCP, the receiving host is expected to send acknowledgement signals back to the transmitting host in order to verify that packets have been properly received.
In standard implementations of TCP, transmission of a data stream begins at a transmitter which divides the data stream into segments containing multiple octets. Each segment is then packaged in a packet, which is then sent onto a network for delivery. During transit, intermediate network devices are permitted to break up a packet into fragments and repackage the smaller segment fragments into multiple packets that are then forwarded to the receiver. Since the receiver will then receive multiple packets corresponding to the single original packet sent from the transmitter, there is not necessarily a one-to-one correspondence between packets sent and packets received.
When a packet is received, the receiver sends an acknowledgement signal (ACK) to the transmitter. The ACK acknowledges receipt of the data stream up to a specified octet sequence number. Thus, the ACK normally contains the last octet sequence number of the most recent packet received. However, in cases where a sent packet is split up into multiple packets during transit, the receiver's ACKs of the various fragmented packets (except the last) specify octet sequence numbers that are less than the last octet sequence number in the original sent packet. Thus, these ACKs are not interpreted by the transmitter as acknowledgements of the whole sent packet. In other words, even though these multiple ACKs are derived from a single packet sent from the transmitter, such ACKs are properly interpreted by the transmitter as corresponding to separate fragmented packets received at the receiver. Note, however, that the ACK signals for such split packets have unique octet sequence numbers, and are not mere duplicates. In fact the following section of the TCP specification RFC 793 published by the Internet Engineering Task Force (http://www.ietf.org/) explicitly declares such ACKs as new or acceptable (i.e. non-duplicate) ACKs:     “In response to sending data the TCP will receive acknowledgments. The following comparisons are needed to process the acknowledgments.     SND.UNA=oldest unacknowledged sequence number     SND.NXT=next sequence number to be sent     SEG.ACK=acknowledgment from the receiving TCP (next sequence number expected by the receiving TCP)     SEG.SEQ=first sequence number of a segment     SEG.LEN=the number of octets occupied by the data in the segment (counting SYN and FIN)     SEG.SEQ+SEG.LEN−1=last sequence number of a segment     A new acknowledgment (called an “acceptable ack”), is one for which the inequality below holds:     SND.UNA<SEG.ACK=<SND.NXT”
Note in particular the inequality condition (“less than equal” rather than “equal”) in the last equation above. Also note that the “sequence number” referred to is the octet sequence number (and not a packet number), as made clear by the following earlier section of the same document:     “The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates.”
According to the TCP protocol, the receiver is allowed to send various types of acknowledgment. A cumulative acknowledgment is an acknowledgment of an entire sequence of data bytes, up to a specified octet sequence number. A cumulative acknowledgment indicates an octet sequence number of the next expected data byte. If a packet is received out-of-order (i.e., the first sequence number of a new packet does not match the sequence number of the next expected byte), then the receiver normally repeats the most recent acknowledgement. Such a duplicate acknowledgments indicates to the transmitter that a packet was lost. It also assumes the packet was lost if the transmitting host receives no acknowledgement before the expiration of a timeout interval.
In TCP, rather than waiting for an acknowledgment of each packet before sending another packet, the transmitting host continues to send packets, stopping only if the number of unacknowledged packets exceeds a specified window size. The transmitting host dynamically adjusts the window size using a flow control technique. When there is no loss, the window size is increased. When a loss occurs, the window size is reduced. The particular flow-control technique determines how exactly the window size is reduced upon detection of a congestion error and how the window size back is again increased. For example, TCP-Reno performs a slow-start followed by congestion avoidance in response to time-out, and performs fast-retransmit (i.e., congestion) in response to three duplicate acknowledgements. TCP-Tahoe performs a slow-start followed by congestion avoidance in both cases. The slow-start technique reduces the window size to one and then doubles the window size after each successful transmission.
Because TCP was developed primarily for use on wired networks, it does not perform well when the network includes lossy links, such as wireless links. The primary reason for its poor performance is because TCP flow-control techniques assume that all types of packet loss are due to network congestion. In the case of a wireless link, however, packets may also be lost because of the lossy nature of the connection, and not only because of congestion. Because TCP assumes that congestion is always responsible for losses, it inappropriately responds to packet loss due to wireless fading as if the loss were due to congestion, e.g., by reducing the window size. This rate back-off mechanism causes the TCP throughput to degrade unnecessarily. Consequently, TCP performance in networks having wireless or other lossy links suffers from throughput degradation due to the inappropriate use of congestion compensation techniques.
Known techniques to improve the performance of TCP over wireless links all require both modifications to the wireless host, and also modifications to the wired host and/or to the wireless gateway node. These prior approaches include, for example, transport layer schemes that require alterations to the TCP implementation. Unfortunately, such alterations can lead to network deadlock and might otherwise be impractical due to backward incompatibility with already established internet hosts. Other approaches are split-connection techniques and link-layer techniques. The split-connection approach breaks the TCP connection into two separate connections: a wired connection between the wired host and the wireless gateway, and a wireless connection between the wireless gateway and the wireless host. This approach suffers from the lack of end-to-end semantics since acknowledgements received at the wired host only indicates reception by the wireless gateway, and not necessarily reception by the wireless host. This approach also has the disadvantage that it requires modification of all wireless gateways to manage the split connections. The link-layer techniques use link-layer mechanisms to make the link layer packet loss probability comparable to that of the wireless link. This improves the transport layer interaction at the cost of link layer throughput, and can be inefficient under some circumstances. This approach also has the disadvantage that it requires modification of all wireless gateways to manage the split connections. All the above approaches have the disadvantage that they require modification to the TCP implementation in hosts of the existing wired network, and/or modifications to the wireless gateway.